Skip to content

feat: postgrest 13 add maxaffected in client libraries #619

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 8 commits into
base: avallete/psql-436-feedback-request-postgrest-js-and-postgrest-v13-integration
Choose a base branch
from

Conversation

avallete
Copy link
Member

@avallete avallete commented May 19, 2025

What kind of change does this PR introduce?

  • Implement the maxAffected postgrest 13 feature at the client level
  • Add tests, introduce a more generic way to handle Prefer header, can be refactor at other places in other PR
  • Refactor the custom made headers handling approach to the standard Headers API
  • Bump minimal node version to the latest LTS v18 (which as support for Headers)

avallete added 2 commits May 19, 2025 09:26
…tgrest-v13-integration' into avallete/psql-372-postgrest-add-maxaffected-in-client-libraries
Comment on lines +343 to +352
/**
* Set the maximum number of rows that can be affected by the query.
* Only available in PostgREST v13+ and only works with PATCH and DELETE methods.
*
* @param value - The maximum number of rows that can be affected
*/
maxAffected(
value: number
): ClientOptions['postgrestVersion'] extends 13
? Method extends 'PATCH' | 'DELETE'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@avallete This works for RPC too, could we add it that? The docs have been updated recently (ref, see RPC at the bottom).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A nice-to-have on typescript would be a validation that the function returns SETOF, otherwise the failure would be at runtime I believe.

Copy link
Member Author

@avallete avallete May 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch didn't tested the rpc they do have their own kind of typing though because they're a bit specifics.

About the "set of" that's actually something I wanna work on. It will be related to "embedded relationships with functions". I have some draft I need to find the time to work on it.

For now I think runtime error is okay, but we'll surely be able to catch that at type level at some point indeed. Just wondering, what if the function doesn't returns a setof but just plain records ? Or return table ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants